Techniques for adapting behavioral pairing to runtime conditions in a task assignment system

ABSTRACT

Techniques for adapting behavioral pairing to runtime conditions in a task assignment system are disclosed. In one particular embodiment, the techniques may be realized as a method for adapting behavioral pairing to runtime conditions in a task assignment system comprising: determining, by at least one computer processor communicatively coupled to and configured to operate in the task assignment system, at least two pairing models for assigning tasks in the task assignment system; monitoring, by the at least one computer processor, at least one parameter of the task assignment system; and selecting, by the at least one computer processor, one of the at least two pairing models based on a value of the at least one parameter.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/701,388, filed Dec. 3, 2019, now U.S. Pat. No. 10,860,371, which is acontinuation of U.S. patent application Ser. No. 16/146,783, filed Sep.28, 2018, now U.S. Pat. No. 10,496,438, each of which is herebyincorporated by reference herein in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to behavioral pairing and, moreparticularly, to techniques for adapting behavioral pairing to runtimeconditions in a task assignment system.

BACKGROUND OF THE DISCLOSURE

A typical task assignment system algorithmically assigns tasks arrivingat the task assignment center to agents available to handle those tasks.At times, the task assignment system may have agents available andwaiting for assignment to tasks. At other times, the task assignmentcenter may have tasks waiting in one or more queues for an agent tobecome available for assignment.

In some typical task assignment centers, tasks are assigned to agentsordered based on time of arrival, and agents receive tasks ordered basedon the time when those agents became available. This strategy may bereferred to as a “first-in, first-out,” “FIFO,” or “round-robin”strategy. For example, in an “L2” environment, multiple tasks arewaiting in a queue for assignment to an agent. When an agent becomesavailable, the task at the head of the queue would be selected forassignment to the agent.

Some task assignment systems prioritize some types of tasks ahead ofother types of tasks. For example, some tasks may be high-prioritytasks, while other tasks are low-priority tasks. Under a FIFO strategy,high-priority tasks will be assigned ahead of low-priority tasks.

In other typical task assignment systems, a performance-based routing(PBR) strategy for prioritizing higher-performing agents for taskassignment may be implemented. Under PBR, for example, thehighest-performing agent among available agents receives the nextavailable task. Other PBR and PBR-like strategies may make assignmentsusing specific information about agents but without necessarily relyingon specific information about tasks.

In some typical task assignment systems, a behavioral pairing (BP) modelmay be generated based on historical task-agent assignment data tooptimize performance of the task assignment system. For example, in acontact center environment, the BP model may be calibrated to optimizerevenue in a sales queue or to reduce average handle time in a sales orcustomer service queue.

In some task assignment systems, a goal for optimizing the taskassignment system or a particular queue of the task assignment systemmay change at runtime (i.e., in real time) based on conditions in thetask assignment system that can change at any moment.

In view of the foregoing, it may be understood that there may be a needfor a task assignment system that can adapt to changing goals atruntime.

SUMMARY OF THE DISCLOSURE

Techniques for adapting behavioral pairing to runtime conditions in atask assignment system are disclosed. In one particular embodiment, thetechniques may be realized as a method for adapting behavioral pairingto runtime conditions in a task assignment system comprising:determining, by at least one computer processor communicatively coupledto and configured to operate in the task assignment system, at least twopairing models for assigning tasks in the task assignment system;monitoring, by the at least one computer processor, at least oneparameter of the task assignment system; and selecting, by the at leastone computer processor, one of the at least two pairing models based ona value of the at least one parameter.

In accordance with other aspects of this particular embodiment, the taskassignment system may be a contact center system.

In accordance with other aspects of this particular embodiment,monitoring the at least one parameter may comprise detecting a change ofstate between an agent surplus and a task surplus

In accordance with other aspects of this particular embodiment,monitoring the at least one parameter may comprise detecting a change insize of a queue of tasks in the task assignment system.

In accordance with other aspects of this particular embodiment,monitoring the at least one parameter may comprise detecting a failureor a recovery in at least one of a site, a server, a switch, and aworkstation of the task assignment system.

In accordance with other aspects of this particular embodiment,monitoring the at least one parameter may comprise detecting a change ina number of agents that is assigned to tasks, available, logged in, oridle.

In accordance with other aspects of this particular embodiment,monitoring the at least one parameter may comprise detecting a change ina time of day or an amount of elapsed time.

In accordance with other aspects of this particular embodiment, at leastone of the at least two pairing models may be a diagonal behavioralpairing model.

In accordance with other aspects of this particular embodiment, at leastone of the at least two pairing models may be a behavioral pairingpayout matrix model.

In accordance with other aspects of this particular embodiment, a goalof one of the at least two pairing models may be one of increasingrevenue, decreasing average handling time, improving customersatisfaction, increasing upgrade/cross-sell rates, and increasingcustomer retention rates.

In another particular embodiment, the techniques may be realized as asystem for adapting behavioral pairing to runtime conditions in a taskassignment system comprising at least one computer processorcommunicatively coupled to and configured to operate in the taskassignment system, wherein the at least one computer processor isfurther configured to perform the steps in the above-described method.

In another particular embodiment, the techniques may be realized as anarticle of manufacture for adapting behavioral pairing to runtimeconditions in a task assignment system comprising a non-transitoryprocessor readable medium and instructions stored on the medium, whereinthe instructions are configured to be readable from the medium by atleast one computer processor communicatively coupled to and configuredto operate in the task assignment system and thereby cause the at leastone computer processor to operate so as to perform the steps in theabove-described method.

The present disclosure will now be described in more detail withreference to particular embodiments thereof as shown in the accompanyingdrawings. While the present disclosure is described below with referenceto particular embodiments, it should be understood that the presentdisclosure is not limited thereto. Those of ordinary skill in the arthaving access to the teachings herein will recognize additionalimplementations, modifications, and embodiments, as well as other fieldsof use, which are within the scope of the present disclosure asdescribed herein, and with respect to which the present disclosure maybe of significant utility.

BRIEF DESCRIPTION OF THE DRAWINGS

To facilitate a fuller understanding of the present disclosure,reference is now made to the accompanying drawings, in which likeelements are referenced with like numerals. These drawings should not beconstrued as limiting the present disclosure, but are intended to beillustrative only.

FIG. 1 shows a block diagram of a task assignment system according toembodiments of the present disclosure.

FIG. 2 shows a block diagram of a contact center system according toembodiments of the present disclosure.

FIG. 3 shows a flow diagram of a task assignment method according toembodiments of the present disclosure.

DETAILED DESCRIPTION

A typical task assignment system algorithmically assigns tasks arrivingat the task assignment center to agents available to handle those tasks.At times, the task assignment system may have agents available andwaiting for assignment to tasks. At other times, the task assignmentcenter may have tasks waiting in one or more queues for an agent tobecome available for assignment.

In some typical task assignment centers, tasks are assigned to agentsordered based on time of arrival, and agents receive tasks ordered basedon the time when those agents became available. This strategy may bereferred to as a “first-in, first-out,” “FIFO,” or “round-robin”strategy. For example, in an “L2” environment, multiple tasks arewaiting in a queue for assignment to an agent. When an agent becomesavailable, the task at the head of the queue would be selected forassignment to the agent.

Some task assignment systems prioritize some types of tasks ahead ofother types of tasks. For example, some tasks may be high-prioritytasks, while other tasks are low-priority tasks. Under a FIFO strategy,high-priority tasks may be assigned ahead of low-priority tasks.

In other typical task assignment systems, a performance-based routing(PBR) strategy for prioritizing higher-performing agents for taskassignment may be implemented. Under PBR, for example, thehighest-performing agent among available agents receives the nextavailable task. Other PBR and PBR-like strategies may make assignmentsusing specific information about agents but without necessarily relyingon specific information about tasks.

In some typical task assignment systems, a behavioral pairing (BP) modelmay be generated based on historical task-agent assignment data tooptimize performance of the task assignment system. For example, in acontact center environment, the BP model may be calibrated to optimizerevenue in a sales queue or to reduce average handle time in a sales orcustomer service queue.

In some task assignment systems, a goal for optimizing the taskassignment system or a particular queue of the task assignment systemmay change at runtime (i.e., in real time) based on conditions in thetask assignment system that can change at any moment.

In view of the foregoing, it may be understood that there may be a needfor a task assignment system that can adapt to changing goals atruntime, as described below.

The description herein describes network elements, computers, and/orcomponents of a system and method for benchmarking pairing strategies ina task assignment system that may include one or more modules. As usedherein, the term “module” may be understood to refer to computingsoftware, firmware, hardware, and/or various combinations thereof.Modules, however, are not to be interpreted as software which is notimplemented on hardware, firmware, or recorded on a non-transitoryprocessor readable recordable storage medium (i.e., modules are notsoftware per se). It is noted that the modules are exemplary. Themodules may be combined, integrated, separated, and/or duplicated tosupport various applications. Also, a function described herein as beingperformed at a particular module may be performed at one or more othermodules and/or by one or more other devices instead of or in addition tothe function performed at the particular module. Further, the modulesmay be implemented across multiple devices and/or other components localor remote to one another. Additionally, the modules may be moved fromone device and added to another device, and/or may be included in bothdevices.

FIG. 1 shows a block diagram of a task assignment system 100 accordingto embodiments of the present disclosure. The task assignment system 100may include a task assignment module 110. The task assignment system 100may include a switch or other type of routing hardware and software forhelping to assign tasks among various agents, including queuing orswitching components or other Internet-, cloud-, or network-basedhardware or software solutions.

The task assignment module 110 may receive incoming tasks. In theexample of FIG. 1, the task assignment system 100 receives m tasks overa given period, tasks 130A-130 m. Each of the m tasks may be assigned toan agent of the task assignment system 100 for servicing or other typesof task processing. In the example of FIG. 1, n agents are availableduring the given period, agents 120A-120 n. m and n may be arbitrarilylarge finite integers greater than or equal to one. In a real-world taskassignment system, such as a contact center, there may be dozens,hundreds, etc. of agents logged into the contact center to interact withcontacts during a shift, and the contact center may receive dozens,hundreds, thousands, etc. of contacts (e.g., calls) during the shift.

In some embodiments, a task assignment strategy module 140 may becommunicatively coupled to and/or configured to operate in the taskassignment system 100. The task assignment strategy module 140 mayimplement one or more task assignment strategies (or “pairingstrategies”) or one more models of a task assignment strategy forassigning individual tasks to individual agents (e.g., pairing contactswith contact center agents). For a given task queue (e.g., a sales queuein a contact center system, a truck roll or field agent dispatch queuein a dispatch queue center, etc.), the task assignment strategy module140 may implement more than one model for more than one condition orgoal. For example, in a sales queue, one goal may be to increase overallrevenue generated by agents processing tasks in the sales queue (e.g.,talking to callers in a call center interested in buying services fromthe company of the agents). A second goal may be to reduce averagehandle time (AHT) for tasks (e.g., complete a sales call relativelyquickly). Historical task-agent pairing data may be available (e.g.,from historical assignment module 150, which is described below) thatincludes both revenue and duration information, and two different modelsor sets of models may be generated that are calibrated to theirrespective goals of increasing revenue or decreasing average handletime.

A variety of different task assignment strategies may be devised andimplemented by the task assignment strategy module 140, and madeavailable to the task assignment module 110 at runtime. In someembodiments, a FIFO strategy may be implemented in which, for example,the longest-waiting agent receives the next available task (in L1environments) or the longest-waiting task is assigned to the nextavailable task (in L2 environments). Other FIFO and FIFO-like strategiesmay make assignments without relying on information specific toindividual tasks or individual agents.

In other embodiments, a PBR strategy for prioritizing higher-performingagents for task assignment may be implemented. Under PBR, for example,the highest-performing agent among available agents receives the nextavailable task. Other PBR and PBR-like strategies may make assignmentsusing information about specific agents but without necessarily relyingon information about specific tasks or agents.

In yet other embodiments, a BP strategy may be used for optimallyassigning tasks to agents using information about both specific tasksand specific agents. Various models of the BP strategy may be used, suchas a diagonal model BP strategy, a payout matrix BP strategy, or anetwork flow BP strategy. These task assignment strategies and othersare described in detail for the contact center context in, e.g., U.S.Pat. Nos. 9,300,802 and 9,930,180, which are hereby incorporated byreference herein. BP strategies may be applied in an “L1” environment(agent surplus, one task; select among multiple available/idle agents),an “L2” environment (task surplus, one available/idle agent; selectamong multiple tasks in queue), and an “L3” environment (multiple agentsand multiple tasks; select among pairing permutations).

In some embodiments, the task assignment strategy module 140 may beconfigured to switch from one task assignment strategy to another taskassignment strategy, or from one model of a task assignment strategy toanother model of the task assignment strategy, in real time. A goal foroptimizing the task assignment system 100 or a particular queue of thetask assignment system 100 may change at runtime (i.e., in real time)based on conditions or parameters in the task assignment system 100 thatcan change at any moment. For example, a condition may be based on thesize of the task queue. When the task assignment system 100 is operatingin L1 (i.e., agent surplus), or the size of the task queue in L2 is lessthan (or equal to) a certain size (e.g., 5, 10, 20 tasks, etc.), thetask assignment system 100 may operate with the goal of increasingrevenue and the task assignment strategy module 140 may select a modelor a set of models corresponding to that goal. When the task assignmentsystem 100 detects that the size of the task queue in L2 is greater than(or equal to) a threshold size, the task assignment strategy module 140may switch to operate with the goal of decreasing average handle timeand switch to a model or set of models corresponding to the new goal.Examples of other goals may include improving customer satisfaction(e.g., customer satisfaction (CSAT) scores or Net Promoter Scores),increasing upgrade/cross-sell rates, increasing customer retentionrates, decreasing AHT, etc. Example of other conditions or parametersmay include switching between L1 and L2 (i.e., switching between agentsurplus and task surplus conditions), unexpected reduction in capacity(e.g., sites/queues/agents workstations/server/switch failure orrecovery), number of agents assigned to the task queue (or number ofagents available/logged in/idle), schedule-based/cycling changes to thegoals and models (which can be benchmarked similarly to benchmarkingON/OFF cycles between two pairing strategies, as described below), timeof the day or amount of elapsed time (for schedule-based cycling ofmodels and benchmarking), etc.

In some embodiments, an operator or manager of the task assignmentsystem 100 may select or switch goals or models manually. In response tothe operator's selection, the task assignment strategy module 140 mayswitch models in real time. In other embodiments, the task assignmentstrategy module 140 may monitor the task assignment system 100 forcertain conditions or parameters and, in response to detectingparticular changes in these conditions or parameters, may select orswitch goals and models automatically. In yet other embodiments, theconditions that trigger switching the goals or models may be determinedautomatically as part of a super- or meta-model from analyzinghistorical task-agent assignment data (available from historicalassignment module 150, which is described below).

In some embodiments, a historical assignment module 150 may becommunicatively coupled to and/or configured to operate in the taskassignment system 100 via other modules such as the task assignmentmodule 110 and/or the task assignment strategy module 140. Thehistorical assignment module 150 may be responsible for variousfunctions such as monitoring, storing, retrieving, and/or outputtinginformation about agent task assignments that have already been made.For example, the historical assignment module 150 may monitor the taskassignment module 110 to collect information about task assignments in agiven period. Each record of a historical task assignment may includeinformation such as an agent identifier, a task or task type identifier,outcome information, or a pairing strategy identifier (i.e., anidentifier indicating whether a task assignment was made using a BPpairing strategy or some other pairing strategy such as a FIFO or PBRpairing strategy).

In some embodiments and for some contexts, additional information may bestored. For example, in a call center context, the historical assignmentmodule 150 may also store information about the time a call started, thetime a call ended, the phone number dialed, and the caller's phonenumber. For another example, in a dispatch center (e.g., “truck roll”)context, the historical assignment module 150 may also store informationabout the time a driver (i.e., field agent) departs from the dispatchcenter, the route recommended, the route taken, the estimated traveltime, the actual travel time, the amount of time spent at the customersite handling the customer's task, etc.

In some embodiments, the historical assignment module 150 may generate apairing model or similar computer processor-generate model based on aset of historical assignments for a period of time (e.g., the past week,the past month, the past year, etc.), which may be used by the taskassignment strategy module 140 to make task assignment recommendationsor instructions to the task assignment module 110. In other embodiments,the historical assignment module 150 may send historical assignmentinformation to another module such as the task assignment strategymodule 140 or the benchmarking module 160.

In some embodiments, a benchmarking module 160 may be communicativelycoupled to and/or configured to operate in the task assignment system100 via other modules such as the task assignment module 110 and/or thehistorical assignment module 150. The benchmarking module 160 maybenchmark the relative performance of two or more pairing strategies(e.g., FIFO, PBR, BP, etc.) using historical assignment information,which may be received from, for example, the historical assignmentmodule 150. In some embodiments, the benchmarking module 160 may performother functions, such as establishing a benchmarking schedule forcycling among various pairing strategies, tracking cohorts (e.g., baseand measurement groups of historical assignments), etc. Benchmarking isdescribed in detail for the contact center context in, e.g., U.S. Pat.No. 9,712,676, which is hereby incorporated by reference herein.

In some embodiments, the benchmarking module 160 may output or otherwisereport or use the relative performance measurements. The relativeperformance measurements may be used to assess the quality of the taskassignment strategy to determine, for example, whether a different taskassignment strategy (or a different pairing model) should be used, or tomeasure the overall performance (or performance gain) that was achievedwithin the task assignment system 100 while it was optimized orotherwise configured to use one task assignment strategy instead ofanother.

FIG. 2 shows a block diagram of a contact center system 200 according toembodiments of the present disclosure. As shown in FIG. 2, the contactcenter system may include a central switch 210. The central switch 210may receive incoming contacts (e.g., callers) or support outboundconnections to contacts via a dialer, a telecommunications network, orother modules (not shown). The central switch 210 may include contactrouting hardware and software for helping to route contacts among one ormore contact centers, or to one or more PBX/ACDs or other queuing orswitching components within a contact center.

The central switch 210 may not be necessary if there is only one contactcenter, or if there is only one PBX/ACD routing component, in thecontact center system 200. If more than one contact center is part ofthe contact center system 200, each contact center may include at leastone contact center switch (e.g., contact center switches 220A and 220B).The contact center switches 220A and 220B may be communicatively coupledto the central switch 210.

Each contact center switch for each contact center may becommunicatively coupled to a plurality (or “pool”) of agents. Eachcontact center switch may support a certain number of agents (or“seats”) to be logged in at one time. At any given time, a logged-inagent may be available and waiting to be connected to a contact, or thelogged-in agent may be unavailable for any of a number of reasons, suchas being connected to another contact, performing certain post-callfunctions such as logging information about the call, or taking a break.

In the example of FIG. 2, the central switch 210 routes contacts to oneof two contact centers via contact center switch 220A and contact centerswitch 220B, respectively. Each of the contact center switches 220A and220B are shown with two agents each. Agents 230A and 230B may be loggedinto contact center switch 220A, and agents 230C and 230D may be loggedinto contact center switch 220B.

The contact center system 200 may also be communicatively coupled to anintegrated service from, for example, a third-party vendor. In theexample of FIG. 2, behavioral pairing module 240 may be communicativelycoupled to one or more switches in the switch system of the contactcenter system 200, such as central switch 210, contact center switch220A, or contact center switch 220B. In some embodiments, switches ofthe contact center system 200 may be communicatively coupled to multiplebehavioral pairing modules. In some embodiments, behavioral pairingmodule 240 may be embedded within a component of a contact center system(e.g., embedded in or otherwise integrated with a switch).

Behavioral pairing module 240 may receive information from a switch(e.g., contact center switch 220A) about agents logged into the switch(e.g., agents 230A and 230B) and about incoming contacts via anotherswitch (e.g., central switch 210) or, in some embodiments, from anetwork (e.g., the Internet or a telecommunications network) (notshown).

The behavioral pairing module 240 may process this information and todetermine which contacts should be paired (e.g., matched, assigned,distributed, routed) with which agents. For example, multiple agents areavailable and waiting for connection to a contact (L1 state), and acontact arrives at the contact center via a network or central switch.As explained above, without the behavioral pairing module 240, a contactcenter switch will typically automatically distribute the new contact towhichever available agent has been waiting the longest amount of timefor an agent under a “fair” FIFO strategy, or whichever available agenthas been determined to be the highest-performing agent under a PBRstrategy.

With a behavioral pairing module 240, contacts and agents may be givenscores (e.g., percentiles or percentile ranges/bandwidths) according toa pairing model or other artificial intelligence data model, so that acontact may be matched, paired, or otherwise connected to a preferredagent.

In an L2 state, multiple contacts are available and waiting forconnection to an agent, and an agent becomes available. These contactsmay be queued in a contact center switch such as a PBX or ACD device(“PBX/ACD”). Without the behavioral pairing module 240, a contact centerswitch will typically connect the newly available agent to whichevercontact has been waiting on hold in the queue for the longest amount oftime as in a “fair” FIFO strategy or a PBR strategy when agent choice isnot available. In some contact centers, priority queuing may also beincorporated, as previously explained.

With a behavioral pairing module 240 in an L2 scenario, as in the L1state described above, contacts and agents may be given percentiles (orpercentile ranges/bandwidths, etc.) according to, for example, a model,such as an artificial intelligence model, so that an agent comingavailable may be matched, paired, or otherwise connected to a preferredcontact.

FIG. 3 shows a task assignment method 300 according to embodiments ofthe present disclosure.

Task assignment method 300 may begin at block 310. At block 310, atleast two pairing models for assigning tasks in a task assignment systemmay be determined. For example, in a sales queue, one pairing model maybe to increase overall revenue generated by agents processing tasks inthe sales queue (e.g., talking to callers in a call center interested inbuying services from the company of the agents). A second pairing modelmay be to reduce AHT for tasks (e.g., complete a sales call relativelyquickly).

Task assignment method 300 may proceed to block 320. At block 320, atleast one parameter of the task assignment system may be monitored. Forexample, a parameter may be the size of the task queue. Example of otherparameters may include a switch between L1 and L2 (i.e., a switchbetween agent surplus and task surplus conditions), unexpected reductionin capacity (e.g., sites/queues/agents workstations/server/switchfailure or recovery), number of agents assigned to the task queue (ornumber of agents available/logged in/idle), schedule-based/cyclingchanges to the goals and models, time of the day or amount of elapsedtime, etc.

Task assignment method 300 may proceed to block 330. At block 330, oneof the at least two pairing models (determined at block 310) may beselected based on a value of the at least one parameter (monitored atblock 320). For example, when the parameter is the size of the taskqueue in the task assignment system and the task assignment system isoperating in L1 (i.e., agent surplus), or the size of the task queue inL2 is less than (or equal to) a certain size (e.g., 5, 10, 20 tasks,etc.), a pairing model that increases revenue may be selected. When thetask assignment system detects that the size of the task queue in L2 isgreater than (or equal to) a threshold size, a pairing model thatdecreases average handle time may be selected.

After selecting one of the at least two pairing models, the taskassignment method 300 may end.

At this point it should be noted that adapting behavioral pairing toruntime conditions in a task assignment system in accordance with thepresent disclosure as described above may involve the processing ofinput data and the generation of output data to some extent. This inputdata processing and output data generation may be implemented inhardware or software. For example, specific electronic components may beemployed in a behavioral pairing module or similar or related circuitryfor implementing the functions associated with adapting behavioralpairing to runtime conditions in a task assignment system in accordancewith the present disclosure as described above. Alternatively, one ormore processors operating in accordance with instructions may implementthe functions associated with adapting behavioral pairing to runtimeconditions in a task assignment system in accordance with the presentdisclosure as described above. If such is the case, it is within thescope of the present disclosure that such instructions may be stored onone or more non-transitory processor readable storage media (e.g., amagnetic disk or other storage medium), or transmitted to one or moreprocessors via one or more signals embodied in one or more carrierwaves.

The present disclosure is not to be limited in scope by the specificembodiments described herein. Indeed, other various embodiments of andmodifications to the present disclosure, in addition to those describedherein, will be apparent to those of ordinary skill in the art from theforegoing description and accompanying drawings. Thus, such otherembodiments and modifications are intended to fall within the scope ofthe present disclosure. Further, although the present disclosure hasbeen described herein in the context of at least one particularimplementation in at least one particular environment for at least oneparticular purpose, those of ordinary skill in the art will recognizethat its usefulness is not limited thereto and that the presentdisclosure may be beneficially implemented in any number of environmentsfor any number of purposes. Accordingly, the claims set forth belowshould be construed in view of the full breadth and spirit of thepresent disclosure as described herein.

1. A method for adapting behavioral pairing to runtime conditions in atask assignment system comprising: determining, by at least one computerprocessor communicatively coupled to and configured to operate in thetask assignment system, at least two pairing models for assigning tasksin the task assignment system; monitoring, by the at least one computerprocessor, at least one parameter of the task assignment system; andselecting, by the at least one computer processor, one of the at leasttwo pairing models based on a value of the at least one parameter. 2.The method of claim 1, wherein the task assignment system is a contactcenter system.
 3. The method of claim 1, wherein monitoring the at leastone parameter comprises detecting a change of state between an agentsurplus and a task surplus.
 4. The method of claim 1, wherein monitoringthe at least one parameter comprises detecting a change in size of aqueue of tasks in the task assignment system.
 5. The method of claim 1,wherein monitoring the at least one parameter comprises detecting afailure or a recovery in at least one of a site, a server, a switch, anda workstation of the task assignment system.
 6. The method of claim 1,wherein monitoring the at least one parameter comprises detecting achange in a number of agents that is assigned to tasks, available,logged in, or idle.
 7. The method of claim 1, wherein monitoring the atleast one parameter comprises detecting a change in a time of day or anamount of elapsed time.
 8. The method of claim 1, wherein at least oneof the at least two pairing models is a diagonal behavioral pairingmodel.
 9. The method of claim 1, wherein at least one of the at leasttwo pairing models is a behavioral pairing payout matrix model.
 10. Themethod of claim 1, wherein a goal of one of the at least two pairingmodels is one of increasing revenue, decreasing average handling time,improving customer satisfaction, increasing upgrade/cross-sell rates,and increasing customer retention rates.
 11. A system for adaptingbehavioral pairing to runtime conditions in a task assignment systemcomprising: at least one computer processor communicatively coupled toand configured to operate in the task assignment system, wherein the atleast one computer processor is further configured to: determine atleast two pairing models for assigning tasks in the task assignmentsystem; monitor at least one parameter of the task assignment system;and select one of the at least two pairing models based on a value ofthe at least one parameter.
 12. The system of claim 11, wherein the taskassignment system is a contact center system.
 13. The system of claim11, wherein the at least one computer processor is configured to monitorthe at least one parameter by detecting a change of state between anagent surplus and a task surplus.
 14. The system of claim 11, whereinthe at least one computer processor is configured to monitor the atleast one parameter by detecting a change in size of a queue of tasks inthe task assignment system.
 15. The system of claim 11, wherein the atleast one computer processor is configured to monitor the at least oneparameter by detecting a failure or a recovery in at least one of asite, a server, a switch, and a workstation of the task assignmentsystem.
 16. An article of manufacture for adapting behavioral pairing toruntime conditions in a task assignment system comprising: anon-transitory processor readable medium; and instructions stored on themedium; wherein the instructions are configured to be readable from themedium by at least one computer processor communicatively coupled to andconfigured to operate in the task assignment system and thereby causethe at least one computer processor to operate so as to: determine atleast two pairing models for assigning tasks in the task assignmentsystem; monitor at least one parameter of the task assignment system;and select one of the at least two pairing models based on a value ofthe at least one parameter.
 17. The article of manufacture of claim 16,wherein the task assignment system is a contact center system.
 18. Thearticle of manufacture of claim 16, wherein the instructions areconfigured to cause the at least one computer processor to operate so asto monitor the at least one parameter by detecting a change of statebetween an agent surplus and a task surplus.
 19. The article ofmanufacture of claim 16, wherein the instructions are configured tocause the at least one computer processor to operate so as to monitorthe at least one parameter by detecting a change in size of a queue oftasks in the task assignment system.
 20. The article of manufacture ofclaim 16, wherein the instructions are configured to cause the at leastone computer processor to operate so as to monitor the at least oneparameter by detecting a failure or a recovery in at least one of asite, a server, a switch, and a workstation of the task assignmentsystem.